COMMENT ⊗   VALID 00005 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.NEWSS USER FEATURES
C00005 00003	.NEWSSS PROGRAM FORMULATION
C00007 00004	.NEWSSS PROGRAM COMPILATION
C00011 00005	.NEWSSS PROGRAM EXECUTION
C00023 ENDMK
C⊗;
.NEWSS USER FEATURES

'AL is designed for users of several varieties; not all of the system
is of use to each of them.  Some users wish to make manipulation
programs with primitive motions.  Others are interested in combining
several often-used library routines in order to make an assembly
program.  More sophisticated users may wish to create library
routines and interact with the intracacies of world modelling.  While
a task is being executed by the manipulator, a user may wish to
monitor its progress, investigate the internal state of the program,
or insert patches in the code to fix errors or attempt some
modification.  Thus, the user may have various degrees of
understanding of the 'AL system, various modes of interaction, and
various reasons for using 'AL. 

The bulk of user interaction with 'AL is during the stage of planning
a set of manipulations.  This planning has several phases: initial
preparation of the program, removing syntactic errors from the source
code, trying the program out, and fixing discovered bugs until the
program works properly.  The final stage is the production run of the
program, which can occur in a basically unsupervised mode. During
execution, however, it is still possible to interrupt the machine and
find out exactly where it is in the plan and debug it further. This
is useful for patching a program which over the course of a long
execution begins to "drift" from reality. 

	Thus, the user features can be divided roughly into these
parts:

.NEWSSS PROGRAM FORMULATION

	The 'AL source language is intended to be a clear and
complete system in which to express those manipulations necessary for
the correct execution of an assembly task.  Writing in 'AL should be
relatively easy; its inherent structure will be great aid in
preparing correct programs. 

	Another way in which 'AL can assist the programmer is that
it can read the current location of an arm and make it available to
the programmer.  This makes some teaching by showing possible.  One way to
put together a simple program is merely to move the arm manually to
the different locations desired, have the system remember those
locations, and then type in appropriate motion commands using these
points. 
In general, a simple "go there" approach fails, because it provides no
way to indicate how fast the arm is to move, what forces to apply,
what errors to ignore and what conditions to monitor.
However, 'AL will allow one to build complete motion specifications
about a skeleton of intermediate points, using textual input
to make up for the limitations of
purely tactile input.

.NEWSSS PROGRAM COMPILATION

	The supervisor is the key to this and the following features;
it allows the user to oversee the progress of the program and fix
errors as they arise.  There is a simple %4supervisor language%* used
to communicate with the 'AL system.  Some of its commands are
demonstrated in the sample dialog given in {apref dia}.  One of the
commands causes compilation to begin; the parser is directed to read
some file.  An option is to have console input itself used to enter
the source code; this is especially useful in causing the arm to do
something immediately. When the parser finds a syntax error, it will
give an error message, and several options will in general be
available.  These include aborting the compilation, skipping to the
end of the current statement, editing the line with the system line
editor (after which the entire statement will be reparsed, if
possible), and temporarily switching to a text editor to fix the
problem (after which the entire program must be reparsed).  

	The compiler detects semantic
errors such as generating a move to a point with undefined planning
value, not supplying enough information to a high-level primitive, or
attempting to move the same arm simultaneously in two blocks of code.
In those cases where the problem is one of insufficient information,
the expander will prompt for more, and, if possible, continue.  The
user may decide not to supply that information, and in that case, the
offending statement is flushed.  Some errors are so drastic that they
require complete recompilation; the user is always given the option
of switching to a text editor for major modifications. 

	The trajectory calculator
can discover a limited number of errors.
These mostly involve motions
beyond the capability of the manipulators involved.  Options to the
user include making the best possible legal trajectory, causing the
trajectory to be slowed down, and inserting a trajectory which, when
executed, does nothing.

.NEWSSS PROGRAM EXECUTION

	After a program has been compiled, it resides on disk as a
load module.  Any number of modules can be loaded together; the
principal restriction is that each of them be a "top level" program.
As mentioned earlier, the loader will resolve calls between the large
(planning) computer and the small (execution) computer for those
functions which the user has decided require the computational
ability found only on the large computer. 

	Execution is initiated by a supervisor command issued
by the user.  While the mini is executing the program, the user can
cause an interruption and examine values within the runtime system,
and modify them if he wishes.  It is also possible to examine the
code generated by the compiler and modify it, but this is most likely
only of interest to system programmers.  Sizable patches require
recompilation. The programmer (or, at this stage, an operator) can
continually examine the status of the runtime system by means of
the mini's console.  Values of variables can be examined and changed,
and individual processes can be interrupted without interfering with
other concurrent processes.

	Sometimes hardware difficulties will cause abrupt termination
of the program; these often are due to runtime trajectory
modifications overstraining the hardware.  After issuing an error
message to the user, the system behaves just as it would should it
have been interrupted manually. 
It is possible, during one of these "breaks", to request that
the entire world be saved.  This causes all runtime values to be
written out into a safe place, along with the current attachment
structure and the current program counters.  
This feature allows the debugging of the task to stop
temporarily and to be resumed later.  More importantly, it is possible
to create a
"safe point" in the code, so that if an error should occur later, it
is possible to back up the program to a point at which everything was
still working. 

	Programs which have been completely debugged can be
"unloaded", that is, saved in a compiled form for execution any time in
the future.